Multimedia publishing system for wireless devices

ABSTRACT

A dynamic publishing system for delivery and presentation of multimedia on a wireless device, such as a PDA or mobile telephone. A presentation server dynamically compiles application data based on scene description data for one or more media objects, and sends the application data to the wireless device for presentation of the media objects. The wireless device has a media player that is able to process the application data at an object level for the objects in response to events, and control the presentation. The application data includes content, layout and control logic data for the media objects.

FIELD OF THE INVENTION

The present invention relates to a publishing system, and in particularto a publishing system for publishing single and multiuser interactiveand dynamic multimedia presentations and applications to wirelessdevices such as cellular phones.

BACKGROUND

A significant problem for publication of rich audio and visual contentto mobile devices results from the significant variations in mobiledevice capabilities, network capabilities, device operating systems andthe difficulty in creating dynamic, interactive media based content.Unlike world-wide web (WWW or WAP content that is predominately textbased, rich media is more sensitive to device capabilities such asdisplay properties and computing power limitations. Existing mobilecomputing/application platforms such as BREW (Binary RunTime Environmentfor Wireless) and J2Me (Java™ 2 Micro Edition) lack key multimediasupport. They also only mainly support static downloadable applications.Many content providers would like to extend their content and brandsinto the mobile space but the lack of consistent support across devicesand the limited computing ability of these devices make them unable tocomposite and render multimedia content.

Current wireless publishing and distribution is limited to one of threebasic models: browsing/text page download via HTML/WAP, streaming mediaas per MPEG, and application download via JAVA/Flash. Messaging may beused in conjunction with these to prompt and direct users to utiliseservices. These models are essentially very different and contentpublishers need to utilise all three if they wish to provide a richservice offering to consumers. In addition to being an expensive andcomplex proposition, this does not present a consistent user experience,with notable demarcations in user interface and functionality betweeneach modality in a single publisher's service offering.

In the browsing/download data model of WAP/xHTML, users are limited topulling down single pages of static text (with some image data) at atime, which provides limited functionality to the user. While the datacontent can be delivered to almost any handset, this ability also comesat the expense of content restrictions and layout limitations, makingpublisher service differentiation difficult. The processes and systemsassociated with this model are limited to the delivery of layout andcontent information to a device, without any function or logic code.

The streaming media model is similar to ‘pay per view’ television, butthe user experience is significantly impeded by device and bandwidthlimitations. Distribution of streaming media is currently limited toniche market mobile devices and provides a passive and expensive userexperience. The systems and processes of this model are essentiallylimited to the delivery of content, without any layout information orlogic.

Application download presents a “shareware” class software-publishingmodel. Like all application software, it is highly functional but mustbe custom written using complex development tools targeting a singlepurpose and a specific handset. These are typically fairly static with alimited lifecycle. Downloading of applications relates to the deliveryof logic, but does not involve the controlled delivery of content andlayout information.

The main problems that publishers are currently faced with whenattempting to build differentiated sophisticated revenue generatingapplications and services are that they are predominantly limited to:

(i) Download (Pull) based delivery;

(ii) Full screen updates only which are unnecessarily slow and costly;

(iii) Fixed or constrained user interfaces;

(iv) Limited multimedia capabilities;

(v) Lack of portability across handsets;

(vi) Complex manual development for sophisticated applications;

(vii) Mainly static applications and content; and

(viii) No clear path to sustainable revenue.

Existing publishing/distribution platforms are predominantly designedfor a single media type based on either text (WAP, HTML), vectorgraphics (FLASH, SVG), or video (MPEG4). Hence to create a rich andvaried experience like that found on the World Wide Web requiresbringing an assortment of different standard and proprietarytechnologies that were designed for desktop class computer terminalstogether using simple yet limiting interfaces. Unfortunately, thesesolutions are too demanding to work on mobile handsets and can onlyprovide a limited multimedia experience, limiting the class ofapplications/content that can be delivered and creating the need formultiple solutions.

Apart from delivering content, these technologies provide very limiteduser functionality and layout capabilities (excepting SVG and Flash);hence they avoid providing the essential separation of content fromfunctionality and form (layout or structure) needed for simple authoringof advanced applications. This means that the layout or structure of anapplication cannot be changed without also changing (or at leastrestating) its entire content and all its functionality, and explainswhy these technologies only operate in page mode. This significantlyconstrains the ability to create dynamic applications and limits thesophistication of applications that can be created.

Most of the existing publishing systems also have limited or poormultiuser capabilities. In the case of the HTML/WAP model, which isdownload based, the system does not lend itself to real-time interactionbetween multiple users since users must redownload a new content page toreceive updates leading to inter-user sycnhronisation problems. In thecase of streaming video multiuser, support is limited to eithernoninteractive media broadcasts or to multiparty video conferencingwhich does not include shared applications and workspaces. Downloadableapplications such as those built using Java and Flash are inherentlysingle user.

In the context of the present specification, the term “multimedia” istaken to mean one or more media types, such as video, audio, text and/orgraphics, or a number of media objects.

It is desired to provide a publishing system or process that alleviatesone or more of the above difficulties, or at least provide a usefulalternative.

SUMMARY OF THE INVENTION

In accordance with the present invention, there is provided a publishingsystem for multimedia, including a presentation server for dynamicallycompiling application data based on scene description data for one ormore media objects, and for sending said application data to a wirelessdevice for presentation of said one or more media objects.

The present invention also provides a media player for a wirelessdevice, including a virtual machine for receiving application data forone or more media objects, processing said application data at an objectlevel for said objects in response to detected events and presentingsaid objects on said device based on said events.

The present invention also provides a publishing system for multimedia,including a presentation server for synchronously accessing mediasources to compile packets for media objects, sending said packets to awireless device to execute an application using the packets received,and adjusting compilation of said packets whilst said wireless deviceruns said application.

The present invention also provides a publishing system for multimedia,including a presentation server for incrementally linking media sourcesfor media objects, and sending said media objects incrementally to awireless device running an application using the objects.

The present invention also provides a publishing system having apresentation server for simultaneously sending application data to aplurality of wireless devices running an application using theapplication data.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention are hereinafterdescribed, by way of example only, with reference to the accompanyingdrawings, wherein:

FIG. 1 is a block diagram of a preferred embodiment of a dynamicmultimedia publishing system (DMPS);

FIG. 2 is a block diagram of a media player client of the DMPS;

FIG. 3 is a block diagram showing data flows to and from a client engineof the media player client;

FIG. 4 is a block diagram of a presentation server of the DMPS;

FIG. 5 is a block diagram of an application server of the DMPS; and

FIG. 6 is a schematic diagram illustrating a tiled image feature of theDMPS.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

As shown in FIG. 1, a dynamic multimedia publishing system (DMPS)includes a database server 102, an application server 104, apresentation server 106, and a media player of a wireless client device108. The application server 104 may communicate with a database server102. The DMPS executes a dynamic multimedia publishing process thatgenerates and executes dynamic multimedia applications with thefollowing features:

-   -   (i) Dynamic content. This permits various types of media sources        to be remapped to display objects in real time, which then        update automatically as the source or “live” data changes.    -   (ii) Dynamic structure. This allows changes to the layout of        on-screen media objects, or the creation and removal from the        screen of new media objects, based on definable events.    -   (iii) Dynamic functionality. The behavior of the application or        media objects can change, based on user or external events.        Based on control packets sent to the wireless device 108, the        user interface generated by the media player can be altered in        real-time as content is presented.

The DMPS allows the delivery of content, layout, and function or logicinformation to a wireless device, the delivery of which can bedynamically controlled by the presentation server 106 and/or the clientdevice 108 on the basis of delivery events or requests sent from theclient device 108.

Using a scene based metaphor, the DMPS permits the creation of complexinteractive applications, where an application is defined as anon-linear sequence of scenes. Each scene defines a spatio-temporalspace in which media type or objects can be displayed. An object canrepresent any kind of live or static media content, including acombination of graphics (SVG), text & forms (HTML), MIDI, audio, tiledimages, and video. A scene provides a framework for describing thestructure or relationships between a set of media objects and theirbehavior. An XML scene description defines these relationships, whichinclude object synchronization, layout and interactions.

The DMPS operates on individual media objects and permits authors toassign conditional event based functional behaviors to objects, and todefine the interactions with objects to trigger these behaviors. Users,the system, or other objects can interact with any defined object toinvoke whatever function the author has defined. Object behaviors can inturn be targeted to act on the system, other objects, or themselves toalter the application structure, media content or assigned functionalbehaviors. Hence users can create applications that have whatevercontent, functionality and structure they desire but also applicationsthat contain any combination of dynamic content, dynamic function ordynamic structure.

This flexibility permits the creation of highly sophisticated andinteractive applications that require advanced user interfaces such asvideo games. Since these can be created using text-based HTML likeauthoring that can be fully automated, their development requiressignificantly less time and cost than is required using handcraftedlow-level programming.

Because the DMPS deals with objects, only displayed media objects thatare changing are updated, for example, streaming text to individual textfields. This reduces latency and costs for users because the sameinformation does not need to be resent to update the display. This isideal for push based live-data feed applications.

In the described embodiment, the database server 102, application server104, and presentation server 106 are standard computer systems, such asan Intel™ x86-based servers, and the wireless client device 106 is astandard wireless device such as a personal data assistant (PDA) or acellular mobile telephone. The computer systems 102 to 106 communicatevia a communications network such as the Internet, whereas the wirelessdevice 108 communicates with the presentation server 106 via a 2G, 2.5G,or 3G wireless communications network. The dynamic multimedia publishingprocess is implemented as software modules stored on non-volatilestorage associated with the servers 102 to 106 and wireless clientdevice. However, it will be apparent that at least parts of the dynamicmultimedia publishing process can be alternatively implemented bydedicated hardware components, such as application-specific integratedcircuits (ASICs). The presentation server 106 is fully scalable, isimplemented in J2SE release 1.4, and runs on any platform that supportsa compatible Java Virtual Machine, including Solaris 8 and Linux.

In the DMPS, the presentation logic is split between the client device108 and the presentation server 106. The presentation server 106 readsan XML-based scene description in SMIL (Synchronised MultimediaIntegration Language, as described at http://www.w3.org/AudioVideo ,IAVML (as described in International Patent ApplicationPCT/AU/00/01296), or MHEG (Multimedia and Hypermedia information codingExpert Group, as described at http:/www.mheg.org), that instructs thepresentation server 106 to load various individual media sources anddynamically create the described scene by resolving the screen/viewportlayout and the time synchronisation requirements for each referencedmedia object. The presentation server 106 uses the scene description tosynchronise and serialise media streams, and inject also control packetsfor the client device 108. The presentation server 106 uses the scenedescription to compile bytecode that is placed in the control packets.The bytecode of the control packets is able to instruct the clientdevice concerning operations to be performed, and also provides layoutand synchronisation information for the client. The scene descriptionalso refers to one or more media sources that have been prepared orencoded for transmission by the application server 104 or which can beobtained from a database. The bitstreams for the content of the sourcesis placed in media data packets for transmission. Media definitionpackets are also formatted for transmission. The media definitionpackets provide format information and coding information for thecontent of the media data packets. The media definition packets may alsoinclude bytecode instructions for initialising an application for themedia player of the client device 108. Unlike the control packets, thebytecode does not control actions during running of the application bythe player.

The actual bitstream 110 pushed to the client device 108 is alsodependent on specific optimisations performed by the presentation server106, which automatically packages the content for each different sessionand dynamically adapts during the session as determined by capabilitiesof the client device 108, network capability, user interaction andprofile/location etc. The scene description script provided to thepresentation server 106 can be dynamically generated by the applicationserver 104, or can be a static file. The client device 108 receives thebitstream, which instructs the client device 108 how to perform thespatio-temporal rendering of each individual object to recreate thespecified scene and how to respond to user interaction with theseobjects.

Media Player Client

As shown in FIG. 2, the client device 108 includes a media playerincluding a media player client 202 and an object library 204, and anoperating system 206. The media player client 202 decodes and processesdefined media objects, event triggers, and object controls, and rendersmedia objects. The media player 202 is a lightweight, real-timemultimedia virtal machine that provides powerful multimedia handlingcapabilities to the client device 108 and maintains an ongoing sessionwith the presentation server 106. The media player client 202 requiresonly 1 MIPS of processing power and 128 kb of heap space. Due to itssmall size of around 60 Kbytes, the media player client 202 can beprovisioned over the air. The media player client 202 is able to run ona wide range of operating systems 206, including BREW, J2ME/MIDP, PPC,PalmOS, EPOC, and Linux.

The media player client 202 includes a client engine 208 thatdecompresses and processes the object data packet stream and controlpacket stream received from the presentation server 106, and renders thevarious objects before sending them to the audio and display hardwareoutput devices of the client device 108. The client engine 208 alsoregisters any events defined by the control packets and executes theassociated controls on the relevant objects when the respective eventsare triggered. The client engine 208 also communicates with thepresentation server 106 regarding the configuration and capabilities ofthe client device 108 and media player client 202, and also in responseto user interaction.

Referring to FIG. 3, the client engine 208 performs operations on fourinterleaved streams of data: the compressed media data packets 302, themedia definition packets 304, the object control packets 306, and uploadexecutable code module packets 308. The compressed data packets 302contain content, ie the compressed media object (eg video) data to bedecoded by an applicable encoder/decoder (codec). The definition packets304 convey media format and other information that is used to interpretthe compressed data packets 302. For example, the definition packets maycontain information concerning a codec type or encoding paramters, thebitstream format, the initial rendering parameter controls, transitioneffects, media format. The object control packets 306 provide logic,structure or layout instructions in bytecode for the client 202. Thecontrol packets define object behaviour, rendering, trigger events,animation and interaction parameters. The upload code module packets 308contain executable software components (such as a specific codec)required to process the data contained in the other three packet types.

The specific packets sent to the client device 108 are determined by thepresentation being viewed, as defined by the scene description, thecapabilities of the client device 108 and the media player client 202,and user interaction with the presentation. The client engine 208 sendsa series of frame bitmaps 310 comprising the rendered scenes to theclient device 108's display buffer 312 at a constant frame rate, whenrequired. It also sends a stream of audio samples 314 to the audiooutput hardware 316 of the client device 108. The client engine 208 alsoreceives user events and form data 318 in response to user input. Itmonitors registered trigger events, executes the associated objectcontrols, and returns relevant events, form data and device/clientinformation 314 back to the presentation server 106. The media playerclient 202 also maintains the local object library 204 for use duringpresentations. The object library 204 is managed by the presentationserver 106.

Unlike most virtual machines (eg Sun's JVM or Microsoft's Net CSharpVM), the media player client 202 operates on media objects at an objectlevel. Like other virtual machines, it executes instructions usingpredetermined bytecode. However, unlike conventional virtual machinesthat are stack based and operate on numbers, the media player client 202is not stack based, but is an event driven virtual machine that operatesat a high level on entire media objects. Thus it avoids spending timemanaging low level system resources.

The media player client 202 permits highly optimized bytecode to be runin real-time without the overheads of having to interpret and resolverendering directives or perform complex synchronization tasks, unlikeexisting browser technologies, allowing it to provide advanced mediahandling and a sophisticated user experience for users. Being fullypredicated, it supports conditional execution of operations on mediaobjects based on user, system and inter-object events. Hence it can beused to run anything from streaming video to Space Invaders tointeractive game-casts.

The media player client 202 handles a wide variety of media types,including video, audio, text, Midi, vector graphics and tiled imagemaps. Being codec independent and aware, any compressed data istransparently decoded on an as needed basis, as long as codec supportexists in the media player client 202 or is accessible on the clientdevice 108.

In stand-alone mode, the media player client 202 can play any downloadedand locally stored application. In client-server mode, the media playerclient 202 establishes a (low traffic) two-way connection with thepresentation server 106 for the duration of an online application'sexecution. The media player client 202 executes instructions as theyarrive in real-time, instead of waiting to download the entireapplication first. This allows delivery of sophisticated multimediaapplications on simple handsets.

The media player client 202 also performs full capability negotiationwith the presentation server 106 so that the latter knows how tooptimise the data it sends to the media player client 202 to achieve thebest possible performance on the client device 108, given the latter'slimitations and network conditions. It also provides security featuresto provide digital rights management functions for publishers.

Presentation Server

As shown in FIG. 4, the presentation server 106 includes a dynamic mediacompositor (DMC) engine 402, a stream transport module 404, a capabilitynegotiator 406, and a storage manager and buffer 408. The DMC engine 402includes a just-in-time XML compiler 410, and a DMC 412. Thepresentation server 106 has four interfaces: a media player connectioninterface provided by the transport module 404 (TCP, UDP or HTTP), ascene description interface to at least a scene database 418(HTTP/HTTPS), a source media interface to a media file database 420(HTTP), and a management interface (HTTP/HTTPS) to the applicationserver 104.

The XML compiler 410 accepts as input a scene description 418 which canbe in a binary format, but is typically in an XML-based language, suchas SMIL or IAVML, or in MHEG. The scene description 418 can be a staticfile or dynamically generated by the application server 104. The XMLscene description 418 defines the specific media objects in a scene,including their spatial layout and time synchronisation requirements,the sequence of scenes, and the user controls and actions to be executedby the media player client 202 when control conditions (events) are metfor a given presentation. The XML scene description 418 also defines howevent notifications and user form data is to be handled by thepresentation server 106 at runtime. The XML compiler 410 compiles theXML scene description 418 into control bytecode for the media playerclient 202, and also generates instructions for the DMC 412 concerningthe media sources that need to be classed and synchronised.

The DMC 412 acts as a packet interleaving multiplexor that fetchescontent and definition data for the referenced media sources, adds thecontrol bytecode, forms packets, drops any packets that are notnecessary, and serialises all the data as a bitstream for transport bythe transport module 404. The DMC 412 interleaves the bytecodes andsynchronised media data from referenced media sources 420 to form asingle, secure and compressed bitstream 110 for delivery to the mediaplayer client 202. The media source objects 420 can be in compressedbinary form or in XML. In the latter case, the application server 104generates a binary representation of the media object and caches it inthe buffer 408. The buffer 408 acts as a storage manager, as it receivesand caches compressed media data and definition data accessed from thesource database 420 or the application server 104. The applicationserver 104 is used to encode, transcode, resize, refactor and reformatmedia objects, on request, for delivery by the presentation server 106.The transcoding may involve media conversion from one media type toanother.

Back-channel user events from the media player client 202 can be used tocontrol the DMC 412. In particular, the DMC engine 402 generates thepresentation bitstream 110 by dynamically compositing the source objectsbased on the scene description as well as the device hardware executionplatform, current client software capabilities and user interaction. Thepresentation server 106 constantly monitors the network bandwidth,latency and error rates to ensure that the best quality of service isconsistently delivered. The capability negotiator 406, based oninformation obtained from the transport module 404, is able to instructthe DMC 412 concerning composition of the stream. This may involveadjusting the content, control or the media definition packets, ordropping packets as required.

If the media player client 202 does not have the capability to renderthe presentation bitstream 110, then the required executablemodules/components are inserted into the bitstream 110 by the DMC 412 tobe uploaded to the media player client 202. These modules/components arestored on the database 420 and uploaded to the media player client 202based on the capability negotiation process of the negotiation 406 whichdetermines the following three things:

-   -   (i) the hardware execution platform of the client device 108;    -   (ii) the current capabilities of the media player client 202;        and    -   (iii) the capabilities required to play the target presentation.

The negotiator 406 uses this capability information to select andinstruct delivery of the appropriate loadable software module to themedia player client 202, if required, in code packets 308. In additionto the upload code and compressed binary media content and a variety ofstandard XML content descriptions (such as HTML 2.0, SVG, MusicXML, NIFFetc) the presentation server 106 can read a range of other native binaryformats, including MIDI, H.263 and MPEG4 from the databases 418, 420 orapplication server 104. In most cases, the server 106 reads the formatand encapsulates/repackages the binary content data contained thereinready for delivery to the media player client 202 with no alteration ofthe bitstream 110 if there is native support on the media player client202 to process it.

The core function of the DMC 402 is to permit the composition ofindividual elementary presentation media objects into a single,synchronous bitstream stream 110 for transmission to the media playerclient 202, as described in International Patent ApplicationPCT/AU/00/01296. The DMC 412 forms the media data packets 302, mediadefinition packets 304, object control packets 306, and the upload codemodule packets 308, based on instructions received from the compiler410, the negotiator 406 and event data (that may be provided directlyfrom the transport module 406 or from the negotiator 406).

The DMC engine 402 permits presentation content to be adapted during asession, while streaming data to the media player client 202, based oninstantaneous user input, predefined system parameters, and capabilitiesof the network, media player client 202, and/or client device 108.Unlike the application server 104 that dynamically adapts individualscene descriptions based on data sources from either returned user formdata or an external data source, the DMC engine 402 adapts based onevents (such as mouse clicks), capabilities or internal system (client108 and presentation server 106 ) based parameters. Specifically, theDMC adaptation encompasses the following:

-   -   (i) adjusting the content media types or temporal or spatial        quality of the presentation based on capabilities of the client        device 108, by passing capability information back to the        application server's transcoding process;    -   (ii) adjusting content to varying bit rate requirements of the        wireless channel at defined time intervals, by dropping of data        packets containing temporal scalability or spatial scalability        enhancement information;    -   (iii) inserting, replacing or deleting individual video or other        media objects in presentation scene, by replacing individual        media input data streams during run-time in response to defined        events;    -   (iv) jumping to new scenes in the presentation, and        hyper-linking to new presentations, by retrieving and compiling        new application descriptions;    -   (v) inserting, replacing or deleting individual animation and        object control parameters or event triggers, as defined in an        application description; and    -   (vi) managing the object library on the client device 108.

The scene description can dynamically request XML-based content (egtext, vector graphics, MDI) or “binary” object data (any form with orwithout object controls) to be composited into an executingpresentation. While the XML compiler 410 can be viewed as a compiler inthe tranditional sense, the DMC 412 can be viewed as an interactivelinker which packages object bytecode together with data resources forexecution. The linker operates incrementally during the entire executionof a server-hosted application and its operation is predicated on byreal-time events and parameters. It also incrementally provides theexecutable code and data to the running client on an “as needed basis”.This also allows the presentation server 106 to synchronously orasynchronously push object update data to a running application insteadof updating the entire display.

The DMC or “linker” synchronously accesses any required media resourcesas needed by a running application, interactively and dynamicallypackaging these together with the application code into a singlesynchronous bitstream. The interactive packaging includes the predicatedand event driven insertion of new media resources, and replacement ofremoval of individual media resources from the live bitstream.

These content object insertions can be an unconditional static (fixed)request, or can be conditional, based on some user interaction as adefined object behavior to insert/replace a new object stream or a userform parameter that is processed inside the DMC engine 402.

The presentation server 106 can operate as a live streaming server, as adownload server, or in a hybrid mode, with portions of an applicationbeing downloaded and the remainder streamed. To provide thisflexibility, the platform is session based, with the media player client202 initiating each original request for service. Once a session isestablished, content can be pulled by the media player client 202 orpushed to the media player client 202 by the presentation server 106.

The presentation server 106 has a number of key and unique roles increating active applications that respond in real-time to a range ofuser or system events. Those roles include:

-   -   (i) dynamic binding of media resources to display objects in the        application;    -   (ii) routing of live data to objects to push updates to the        screen;    -   (iii) managing the just-in-time delivery of content, and        application bytecodes to the media player client 202 to reduce        network latency;    -   (iv) managing media player client 202 caches and buffers to        reduce unnecessary data transfers;    -   (v) run-time creation and removal of onscreen objects;    -   (vi) run-time assignment and management of object behaviors;    -   (vii) run-time control of scene layout; and    -   (viii)real-time adaptation of data being transmitted to the        media player, based on network bandwidth, handset capabilities,        or system (e.g., location/time) parameters.

AU of these functions of the DMC engine 402 are interactively controlledduring execution of an application by a combination of internal system,external data and/or user events.

Application Server

The application server 104 monitors data feeds and provides content tothe presentation server 106 in the correct format and time sequence.This data includes the XML application description and any static mediacontent or live data feeds and event notifications. The applicationserver 104, as mentioned above, is responsible for encoding,transcoding, resizing, refactoring and reformatting media objects fordelivery by the presentation server 106. As shown in FIG. 5, theapplication server 104 includes intelligent media transcoders 502, a JSPengine 504, a media monitor 506, a media broker 508, and an SMILtranslator 510. The application server 104 is J2EE™-compliant, andcommunicates with the presentation server 106 via a standard HTTPinterface. The Java™ 2 Platform, Enterprise Edition (J2EE™) is describedat http://java.sun.com/j2ee.

The use of dynamic content, such as Java Server Pages (JSP) and ActiveServer Pages (ASP), with the application server 104 permits more complexdynamic presentations to be generated than the simple object insertioncontrol of the presentation server 106, through the mechanism ofparameterized functional outcalls (which return no data) made by itselfto a database server 102 or by the presentation server 106 to theapplication server 104. The application server 104 processes thesecallout functions and uses them to dynamically modify a presentation ora media source, either by controlling the sequencing/selection of scenesto be rendered, or by affecting the instantiation of the next scenedescription template provided to the presentation server 106. Forexample, the scene description template can be customised duringexecution by personalization, localization, time of day, thedevice-specific parameters, or network capability.

While the main output of the application server 104 is a scenedescription (in SMIL, IAVML, or MHEG) 418, the application server 104 isalso responsible for handling any returned user form data and making anyrequired outcalls to the database server 102 and/or any other backendsystems that may provide business logic or application logic to supportapplications such as e-commerce, including reservation systems, productordering, billing, etc. Hence it interfaces to business logic 512 tohandle processing of forms returned from the client device 108. Theapplication server 104 is also responsible for accepting any raw XMLdata feeds and converting these to presentation content (eg graphics ortext objects) via an XSLT process, as described athttp://www.w3.org/TR/xslt.

As shown in FIG. 5, the application server 104 includes intelligentmedia transcoders 502, a JSP engine 504, a media monitor 506, a mediabroker 508, and an SMIL translator 510. It also interfaces to businesslogic 512 to handle processing of forms returned from the client device108. The application server 104 is J2EE™-compliant, and communicateswith the presentation server 106 via a standard HTTP interface. TheJava™ 2 Platform, Enterprise Edition (J2EE™) is described athttp://java.sun.com/j2ee.

Under the control of the media broker 508, intelligent transcodingbetween third party content formats and standard or proprietary formatspermits existing media assets to be transparently adapted according tocapabilities of the client device 108. The media broker 508 is anEnterprise Java Bean (EJB) that handles source media requests from thepresentation server 106. It automates the transcoding process asrequired, utilizing caching to minimize unnecessary transcoding, andmaking the process transparent to users. The transcoders 502 are EJBsthat support the following media and data formats: graphics (SVG,Flash), music (MIDI, MusicXML), images (JPEG, PNG, GIF, BMP), text/forms(xHTML, ASCII, HTMEL), video (AVI, H263, MPEG), audio (WAV, G.721,G.723, AMR, MP3), and alternate scene descriptions (SMIL, XMT).

The media monitor 506 handles asynchronous changing media sources suchas live data feeds 514. It notifies the presentation server 106 ofchanges in the source media, so that it may reload the source media andupdate the content displayed in the media player 202, or, alternatively,jump to a different scene in a presentation.

Media Objects and Bitstreams

A media object can be defined by a set of media data packets, mediadefinition packets and control packets, which are all identified by aunique tag.

In the presentation structure each media data packet contains all of thedata required to define an instance of the media object element for aparticular discrete point in time. In essence a packet encapsulates asingle sample of the object element in time. Object control packetssimilarly encapsulate control signals that operate on the object atdiscrete instances in time and appear in correct time sequence within anobject stream. This is true for all media objects except for tiled imagedata packets. With tiled images, described below, a media data packetprimarily contains all of the data required to define an instance of theobject for a particular region (instance) in space. While a tile imageobject as a whole is localised in time, each packet is primarilylocalised in space. This difference in the semantics of tile image datapackets extends to object control packets as well where these are notlocalised primarily in time but in space, specifically mapping toindividual image tile locations. Hence tile image control packets do notoccur in time sequence in the format, but in space sequence, wherefollowing a tile image data packet, zero or more control packets thatrelate to the data packet may follow.

The definition packets define the structure and interpretation of mediaspecific codec bit streams. The media data packets encapsulate thecontent in the form of compressed media elements.

The object control packets convey the functions or operations to beperformed on content file entities that permit control over rendering,data transformation, navigation and presentation structures.

Media data entities may be either static, animated or evolving overtime. The static case consists of a single, invariant instance and is asubset of animated, which provides for deterministic change from adiscrete set of alternatives, often in a cyclical manner, whereasstreaming is continuous, dynamic, non-deterministic evolution. Theupdate in the case of animated or evolution may be time motivated orcaused by some asynchronous update event. These three characteristicsapply not just to the media content but also the structure and thecontrol in a presentation. Examples of these characteristics in terms ofthe content are shown in Table 1. TABLE 1 Time Motivated Update EventDriven Update Static — Still Picture, Text Message Animated Video SpriteSlide Show Evolving Streaming Video Game-Cast Data-FeedFor presentation content, support for static, animated and evolutionarydata is provided by the DMPS system requirements for handling mediaelements:

-   -   (a) Static media is stateless and requires all the data that        defines the element to be delivered in its entirety at one time        to the client for rendering. Static media requires one        definition and one data packet. This media type requires event        based (random) access by the client. Both time and event driven        updates are the same.    -   (b) Streaming media requires new incremental data to dynamically        update the state of the element to create a new instance of it,        and this is valid for a time interval before it must be renewed.        Only the state of the current instance needs to be stored; it        requires a single definition packet but an undefined number of        data “update” packets that are sequentially accessed and        processed by the client. Both time and event driven updates are        essentially the same.    -   (c) Animated media is based on performing a discrete set of        updates on a given media element. For media that is defined        atomically these updates typically modify one or more atoms        rather than create an entire new instance. The updates may occur        in a predetermined order after which the element reverts to its        original state and the process reiterated. In the case of        time-based update the sequence is always constant (eg sprites)        whereas in event-based update the sequence is typically random.        Both random and sequential access is required for animations. To        reduce unnecessary decoding and transport a definition packet        and fixed number of decoded data packets is stored at the        client, memory permitting. With event driven media animation,        the simplest method to support this is through object replace        controls on a single object from a set of streams.

For presentation structure, the need to support static, animated andevolutionary modification of scenes is supported via definition andobject control packets:

-   -   (a) Static structure—This requires only one scene definition and        fixed object definitions used.    -   (b) Streaming structure—This can be primarily achieved by        replacing a scene with an entire new instance, as each scene        must be self-contained. The alternative mechanism that provides        incremental evolution uses object control mechanisms to        dynamically create and delete objects within a given scene. This        is achieved by using empty object templates that serve as        targets for arbitrary object replace operations.    -   (c) Animated structure—This is more constrained than streaming        and is supported through object controls to create a limited set        of transitory structural alterations such as implicit object        grouping. For example, events on one object can cause actions on        various other objects and a single action be applied to multiple        objects at once.

For presentation control, the need to support static, animated andevolutionary modification of function is supported via the objectcontrol packets:

-   -   (a) Static Control—This usually requires initial object controls        to be present.    -   (b) Streaming Control—This usually requires new object controls        to be available to replace existing ones.    -   (c) Animated Control—As this provides for a limited set of        often-cyclical controls these can be predefined and supported        via an animation extension to object definitions.        Multiuser Support

In the case of publishing and delivering multi-user applications such ascollaborative work environments or multi-user games the DMPS essentiallyoperates in the same manner as for single user applications where thepresentation server and media player in consort execute the presentationlogic and the user interface while the application server hosts theapplication logic. Due to the flexibility and functionality requirementsof typical interactive multiuser applications such as multiplayer gamesgenerally, these are normally built as highly customised and monolithicapplications. The DMPS permits multiuser applications to be constructedwith reduced effort since the user interface and presentation logiccomponents are already present in the presentation server and the mediaplayer and the application server need only provide to each user thecorrect “view” of the application display data and availablefunctionality at each instance in time. The presentation server alsoprovides back to the application server the respective events from eachuser that is used to modify the shared application data. This ispossible because as part of the capability negotiation each media playeruniquely identifies itself to the presentation server using a user IDand this is passed to the application server when requesting the view ofthe shared data and passing events to the application server.

Download Applications

In the case of downloaded applications the essential difference fromonline applications is that the DMC 412 runs in batch mode and anapplication must be fully downloaded to the media player beforeexecution of the application begins. Other than this the process isessentially the same as for online applications. When a client requestsan application download the media player provides its capabilities tothe presentation and publishing server. The publishing server transcodesand reformats the media as required for the specific handset andprovides this to the presentation server for packaging up with theobject controls, which processes the entire application and optionallycache the generated output bit stream to delivery to one or moredevices.

In the case of a hybrid application a two stage creation process isrequired. First a “static” portion of the application is created fordownloading to the application via a third party distribution mechanism,and the “dynamic” or online application is created.

The static downloaded portion of the application mainly consists of astart scene with one or more auxiliary scenes and an optional set ofobjects for preloading into the systems object library. This part of theapplication (static download portion) contains at the least thefollowing:

-   -   (i) A startup scene with an automatic or event triggered        sceneJump to a URI on the application's host server.    -   (ii) An optional library preload scene.    -   (iii) A valid uniqueAppID in a Scenedefn packet to identify the        application.    -   (iv) Version number in the Scenedefn packet to identify the        application.

When a JumpURI command is executed on the client, referrer data ispassed to the target presentation server consisting at the least of theuniqueAppID. This permits the presentation server to know what preloadedresources are available on the client object library.

Tiled Image Support

The DMPS provides tiled image support that permits advanced functionssuch as smooth panning and zooming with minimal transmission overhead,and video game support. As shown in FIG. 6, this is achieved by dividingsource pictures at the presentation server 106 that exceed a referencepicture size into small rectangles 602 to provide a tiled representation604, where each tile can be managed separately. The entire image canexceed the display dimensions of the client device 108 by a significantamount, but only those tiles visible at any time need be delivered tothe media player client 202 by the presentation server 106 and rendered.This eliminates unnecessary data transmission between the client device108 and the presentation server 106. Specific features of thiscapability include:

-   -   (i) panning or scrolling in vertical, horizontal and diagonal        directions;    -   (ii) zooming, which provides multiple levels of information, not        only resolution. This is achieved by providing the tile data in        a spatial scalable format that supports different layers of        resolution in more than one direction. The tile data includes        different tiles for different layers of resolution, and is        generated by a codec that supports the spatial scalable format;    -   (iii) progressive display update (where supported by the codec)        whereby the image is displayed as data is received,        progressively increasing the image resolution;    -   (iv) spatial scalability, so that the system is capable of        operating with client devices of various screen resolutions. The        same view can be specified on different size screens (where        supported by the codec).

Tile data can also be provided that allows larger images to be generatedby the client device 108 from the tile data received. For example, a fewtiles can be used in a video game to generate a larger scene image.

These image capabilities allow the DMPS to optimise the provision ofdata, as dictated by user requirements and device attributesparticularly screen size). The user is able to navigate across a largeimage, zooming in and out as required, yet only receive the exact amountof data they require for the current display. This reduces both theresponse time and the data transmission costs. In addition, the mediaplayer client 202 updates the display with data as it is received, whichallows the user to make choices/selections prior to receiving all thedata for that screen, again reducing the response time and cost.

To provide this function, image data is stored on the presentationserver 106 as a set of tiles 602 at various levels 606 ofdetail/resolution. This granular storage permits the relevant datacomponents to be sent to the media player client 202 on an as-neededbasis as the user navigates through the image by either zooming orpanning. This can also be used to provide scrolling backgrounds for gameapplications. A directory packet stored with the image tiles defines themapping between each tile and its coordinate location in the image. Thisalso permits a single image tile to be mapped to multiple locationswithin the image, and specific object control/event trigger to beassociated with each tile for supporting games.

Media Object Controls

Each media object in a presentation can have one or more controlsassociated with it, in addition to scene-based controls and image tilecontrols. Object controls include conditions and an action as a set ofbytecodes that define the application of one or more processingfunctions for the object. The control actions are all parameterised. Theparameters can be provided explicitly within the control itself, or theycan be loaded from specific user registers. Each control can have one ormore conditions assigned to it that mediate in the control actionexecution by the client software. Conditions associated with one objectcan be used to execute actions on other objects as well as itself. Table2 provides the possible conditions that can be applied. TABLE 2Condition Description Negate If set the condition is negatedUnconditional Execute action unconditionally UserFlag Test bits insystem Boolean variables UserValue Test value of system integer registervariables UserEvent Test for user events; e.g., specific key pressed, orpen event on various parts of objects, etc. TimerEvent Test for systemtimer event Overlap Test for object overlap and direction sensitivecollision detection between objects ObjLocation Test for specific Objectpositioning on the screen Source Is data being streamed from a server orlocal play PlayState Is player paused or playing BufferState Is thebuffer empty or full

Table 3 provides the range of actions that may be executed include inresponse to a condition being met. TABLE 3 Actions Process DescriptionProtect Local Limit user interaction with object JumpToScene Either Jumpto new place in presentation/application ReplaceObject Local & Replacesan object in the current scene with Remote a different object, alsoadd/delete objects Hyperlink Remote Close presentation and open new oneCreate/Destroy Both Enables the instantiation of new media objectsObject or the destruction of existing media objects PurgeControls LocalResets the state of each object SetTimer Local Initializes and starts asystem timer Animate Local Defines animation path for objects MoveToLocal Relocate objects in scene Zorder Local Change object depth orderRotate Local Rotate objects in 3D Alpha Local Change object transparencyvalue Scale Local Change object size Volume Local Change sound volume ofobjects audio stream Register Local Perform operation using values insystem Operation registers and object parameters CondNotify RemoteNotify server of the event or condition that just occurred such aspanning a tiled image - or any of the other remotely processed actionsthat have been invoked.Capability Negotiation

The capability negotiation between the media player client 202 and thepresentation server 106, controlled by the negotiator 406, permitsmicro-control over what specific data is delivered to the media playerclient 202. This process is referred to as data or content arbitration,and specifically involves using the client device 108's capabilities atthe presentation server 106 to:

-   -   (i) modify presentations in order to provide an optimal viewing        experience on the client device 108, including packet dropping        (temporal scalability), and resolution dropping (spatial        scalability);    -   (ii) determine what presentation to send or what media to drop        for devices that do not support particular media types; and    -   (iii) update or install appropriate software components in the        client device 108. The upload components are treated as another        media source by the DMC 412.

In the first instance of data arbitration, the data sent to the mediaplayer client 202 is adapted to match the existing capabilities of theclient device 108 (eg processing power, network bandwidth, displayresolution, and so on) and the wireless network. These properties areused to determine how much data to send to the client device 108depending on its ability to receive and process the data.

A second instance of data arbitration depends on the support in theclient device 108 for specific capabilities. For example, some clientdevices may support hardware video codecs, while others may not have anyaudio support. These capabilities may be dependent on both the clientdevice hardware and on which software modules are installed in theclient device. Together, these capabilities are used to validate contentprofiles stored with each presentation to ensure playability.Specifically, the profiles defined the following basic capabilities:

-   -   (i) installation of software updates;    -   (ii) digital rights protection;    -   (iii) interaction—includes multi-object;    -   (iv) audio support;    -   (v) music support;    -   (vi) text support;    -   (vii) video support; and    -   (viii) image support.

Additionally, the DMPS supports, at a high level, six pre-defined levelsof interactive media capabilities, as provided in Table 4 below,providing various levels of required functionality. These are comparedto the media player client 202 's capabilities to determine whether theapplication is supported. More detailed lower levels are also supported.

The content adaptation/arbitration modifies a presentation through thefollowing mechanisms:

-   -   (a) Automatic Presentation Server DMC control over what specific        packets to send/drop at any instance in a presentation, for        example (packets providing temporal or spatial scalability).    -   (b) Automatic Publishing server transcoding and adaptation (ie        rescaling) of source media as needed based on target device.

The capability negotiation process determines:

-   -   (a) What is the client's hardware execution platform (eg Screen        size, CPU, memory etc).    -   (b) What the current client software capabilities are (eg player        version, codecs, etc).    -   (c) What capabilities are required to play the target content as        defined by a profile.    -   (d) Also network QoS at any instance during the session.

The DMPS executes the following process:

-   -   (i) A ConfigDefn packet is sent from the client to the        presentation server at the start of a session.    -   (ii) Depending on information in ConfigDefn packet the        presentation server may elect to query a device database to        extract additional information not supplied in this packet.        Alternatively it may elect to update information in device        configuration database.    -   (iii) Depending on information in ConfigDefn packet the        presentation server may elect to further query the device to        ascertain the presence of specific codec or other component        support.    -   (iv) The presentation server estimates channel bandwidth.    -   (v) The presentation server requests indicated presentation        (scene+source media descriptors) by passing selected device        config parameters to the application server.    -   (vi) The JSPs can be used to process the SMIL/IAVML according to        the config parameters    -   (vii) When requesting media data the presentation server        suitably instructs (codec, format etc) the application server        transcoders to generate full quality elementary media compressed        data files and deliver them to presentation server to be cached.        It may return an access denied message if certain config        parameters such as specific media type support are not met.    -   (viii)If a device does not have enough processing speed to        render a particular compressed media data (video or audio) and        the application server was unable to provide a more lightweight        compression method then the device is considered incapable of        supporting that media type    -   (ix) The presentation reads the generated compressed media data        and dynamically drops selected packets during the presentation        to meet the device capability and varying QoS constraints.

The application server executes the following process:

-   -   (i) JSP engine/SMIL decides whether presentation may be accessed        by checking the following:        -   a. Media type support capabilities (eg must have video etc);        -   b. Specific Device (eg PDA vs handset or BREW vs J2ME)        -   c. Specific network bandwidth (vs any target presentation            bandwidth)    -   (ii) Transcoders encode media based on device capabilities        including:        -   a. Screen size based on both device display and presentation            scaling mode        -   b. CPU speed based on SkyMIPS device rating & codec            performance requirements, eg            -   i. for video on devices with 200 MIPS use H.263 video                codec            -   ii. for video on devices with 20 MIPS use ASG video                codec            -   iii. for video on devices with 1 MIPS use VLP video                codec            -   iv. for audio on devices with 200 MIPS use ACC audio                codec            -   v. for audio on devices with 20 MIPS use IMA audio codec        -   c. Channel bit rate: adjust quality setting on codecs to            achieve target bit rate limitations        -   d. Platform limitations, for example            -   i. For MIDP 1.0 platforms, transcode all text data and                images into a PNG bitmap            -   ii. For platforms with hardware codecs, either just                encapsulate (repackage) the data into a binary file                transcode into the supported codec if required

The DMC 412 of the presentation server executes the following process:

-   -   1. Upon a packet loss error automatically resend the following        packet types: Any-Defn, ObjCtrl, VideoKey, ImageKey, ImageDat,        TextDat, GrafDat, MusicDat (VideoKey and ImageKey are media data        packets). The following are not resent VideoDat and its        derivatives or AudioDat.    -   2. If there is a video packet loss then send next available        VideoExtn (a data) packet to fix error else pause the        presentation until next VideoKey packet.    -   3. If presentation data rate>available channel bit rate at any        instance then drop video packets in the following order, first        drop all VideoTrp (data) packets then drop all VideoDat packets,        finally drop AudioDat. When videodat or audiodat packets are        present tine synchronization is preserved, and presentation        pauses during rebuffering minimized.

4. If a device does not support MusicDat or AudioDat then all music andaudio packets present in the presentation are discarded. TABLE 4 LevelName Description 0 AudioVideo Audio + video only, Single object, NoObjCtrl 1 ImageMap Single image map based application only, (pan, zoom)2 Elementary Single object, any media, no interaction 3 StillActive Upto 200 objects, no continuous media (i.e., audio/video) only text,music, images, graphics hotspots, very limited interaction (click, move,jump). 4 VideoActive Limited interaction single video object withtransparent Vector graphics hotspots only, very limited interaction(jumps). 5 Interactive Multi-object, per object controls

The simplest implementation (AudioVideo at level 0) provides a passiveviewing experience with a single instance of media and no interactivity.This is the classic media player where the user is limited to playing,pausing and stopping the playback of normal video or audio. TheStillActive and VideoActive levels add interaction support to passivemedia by permitting the definition of hot regions for click-throughbehaviour. This is provided by creating vector graphic objects withlimited object control functionality. Hence the system is not literallya single object system, although it would appear so to the user. Apartfrom the main media object being viewed transparently, clickable vectorgraphic objects are the only other types of objects permitted. Thisallows simple interactive experiences to be created such as non-linearnavigation, etc. The final implementation level (level 5, Interactive)defines the unrestricted use of multiple objects and full object controlfunctionality, including animations, conditional events, etc. andrequires the implementation of all of the components.

The third instance of data arbitration includes capability negotiation.This involves determining what the current software capabilities are inthe media player client 202 and installing new functional modules toupgrade the capabilities of the media player client 202. This functioninvolves the presentation server 106 sending to the media player client202 data representing the executable code that must be automaticallyinstalled by the media player client 202 to enhance its capabilities byadding new functional modules or updating older ones.

Many modifications will be apparent to those skilled in the art withoutdeparting from the scope of the present invention as herein describedwith reference to the accompanying drawings. For example, thepresentation server 104 may incorporate all the functionality andcomponents of the application server 106

1. A publishing system for multimedia, including a presentation serverfor dynamically compiling application data based on scene descriptiondata for one or more media objects, and for sending said applicationdata to a wireless device for presentation of said one or more mediaobjects.
 2. A publishing system as claimed in claim 1, wherein saidapplication data includes content, layout and control logic data forsaid media objects.
 3. A publishing system as claimed in claim 2,wherein said presentation server communicates with said wireless deviceand said compiling is controlled on the basis of communications betweensaid presentation server and said wireless device.
 4. A publishingsystem as claimed in claim 1, wherein said compiling is controlledduring delivery of said application data to said wireless device.
 5. Apublishing system as claimed in claim 4, wherein said control logic datacomprises bytecode for a virtual machine of said wireless device, andsaid application data is for content requested by said wireless deviceand is adjusted in real-time during said compiling on the basis ofevents detected by said virtual machine.
 6. A publishing system asclaimed in claim 5, wherein said events are defined by said logic data.7. A publishing system claimed in claim 6, wherein said events relate toactions of a user of said wireless device.
 8. A publishing system asclaimed in claim 1, wherein said scene description data defines one ormore scenes including one or more media objects, rendering of said oneor more media objects and one or more events associated with said one ormore multimedia objects.
 9. A publishing system as claimed in claim 8,wherein said application data includes interleaved control packets,media data packets and media definition packets for said media objects.10. A publishing system as claimed in claim 8, wherein said scenedescription data includes XML data.
 11. A publishing system as claimedin claim 3, wherein said compiling is adjusted on the basis of one ormore characteristics of the communications link between saidpresentation server and said wireless device.
 12. A publishing system asclaimed in claim 3, wherein said presentation server is adapted toreceive capability data from said wireless device indicatingcapabilities of said wireless device and to modify said application dataon the basis of said capability data.
 13. A publishing system as claimedin claim 12, wherein said capabilities include hardware capabilities andsoftware capabilities of said wireless device.
 14. A publishing systemas claimed in claim 13, wherein said presentation server is adapted tosend software packets to said wireless device on the basis of saidcapability data to modify software capabilities of said wireless device.15. A publishing system as claimed in claim 1, wherein said presentationserver is adapted to manage a multimedia object library stored on saidwireless device.
 16. A publishing system as claimed in claim 2, whereinsaid presentation server is adapted to receive user form data and eventsfrom said wireless device.
 17. A publishing system as claimed in claim1, including an application server for communicating with saidpresentation server, providing encoded data for said media objects, andgenerating said scene description data.
 18. A publishing system asclaimed in claim 17, wherein said application server includes an enginefor generating said scene description data on the basis of dynamicpages.
 19. A publishing system as claimed in claim 17, wherein saidapplication server is adapted to process user form data sent from saidwireless device to said presentation server.
 20. A publishing system asclaimed in claim 1, wherein said application server is adapted togenerate image tile data representing an image as a set of tiles and tosend at least part of said image tile data to said wireless device fordisplay of part of said image.
 21. A publishing system as claimed inclaim 19, wherein said presentation server is adapted to send individualtiles of said set of tiles to said wireless device on demand.
 22. Apublishing system as claimed in claim 4, wherein said presentationserver synchronously accesses media sources for said media objects andsends said application data in packets of a bitstream to said wirelessdevice, whilst said wireless device is executing an application usingthe application data received.
 23. A publishing system as claimed inclaim 1, wherein said presentation server incrementally links mediasources for said media objects and sends said application dataincrementally to a wireless device running an application using thereceived application data.
 24. A publishing system as claimed in claim1, wherein said presentation server is adapted to send said applicationdata to a plurality of wireless devices running an application using theapplication data, simultaneously.
 25. A publishing system as claimed inclaim 1, wherein said presentation server sends said application data tosaid wireless device as a download.
 26. A publishing system as claimedin claim 1, wherein said presentation server sends said application datato said wireless device as a data stream.
 27. A publishing system asclaimed in claim 1, wherein said presentation server sends a portion ofsaid application data to said wireless device as a download, and theremainder of said application data as a data stream.
 28. A media playerfor a wireless device, including a virtual machine for receivingapplication data for one or more media objects, processing saidapplication data at an object level for said objects in response todetected events and presenting said objects on said device based on saidevents.
 29. A media player as claimed in claim 28, wherein saidapplication data includes content, layout and control logic data forsaid media objects.
 30. A media player as claimed in claim 29, whereinsaid logic data defines events for said media objects, respectively. 31.A media player as claimed in claim 29 or 30, wherein said content,layout and logic data is sent in media data packets, media definitionpackets and object control packets, said object control packetsincluding bytecode for instructing said virtal machine.
 32. A mediaplayer as claimed in claim 28, wherein said virtual machine communicateswith a presentation server and compilation of said application data isdynamically controlled on the basis of communications between thevirtual machine and the presentation server.
 33. A media player asclaimed in claim 32, wherein said virtual machine is adapted to sendcapability data to a presentation server indicating capabilities of saidwireless device.
 34. A media player as claimed in claim 33, wherein saidcapabilities include hardware capabilities and software capabilities ofsaid wireless device.
 35. A media player as claimed in claim 32, whereinsaid communications includes data on said events.
 36. A media player asclaimed in claim 35, wherein said events relate to actions of the userof said wireless device.
 37. A media player as claimed in claim 32,wherein said virtual machine is adapted to send user event data to saidpresentation server.
 38. A media player as claimed in claim 32, whereinsaid presentation server is adapted to receive software packets from apresentation server to modify software capabilities of said wirelessdevice.
 39. A media player as claimed in claim 32, wherein saidpresentation server is adapted to manage a multimedia object librarystored on said wireless device.
 40. A media player as claimed in claim32, wherein said virtual machine is adapted to receive image tile datafrom said presentation server and to display individual tiles of animage.
 41. A media player as claimed in claim 40, wherein said virtualmachine is adapted to allow zooming and panning of said image on thebasis of said image tile data.
 42. A media player as claimed in claim41, wherein said virtual machine is adapted to request individual tilesof said image tile data from said presentation server when required. 43.A media player as claimed in claim 28, wherein said virtual machinereceives said application data as a data stream.
 44. A media player asclaimed in claim 28, wherein said virtual machine receives saidapplication data as a download.
 45. A media player as claimed in claim28, wherein said virtual machine receives a portion of said applicationdata as a download and the remainder of said application data as a datastream.
 46. A publishing system for multimedia, including a presentationserver for synchronously accessing media sources to compile packets formedia objects, sending said packets to a wireless device to execute anapplication using the packets received, and adjusting compilation ofsaid packets whilst said wireless device runs said application.
 47. Apublishing system for multimedia, including a presentation server forincrementally linking media sources for media objects, and sending saidmedia objects incrementally to a wireless device running an applicationusing the objects.
 48. A publishing system having a presentation serverfor simultaneously sending application data to a plurality of wirelessdevices running an application using the application data.